<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<title>Common tasks</title>
<link rel="stylesheet" href="../../../doc/src/boostbook.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="../index.html" title="The Boost C++ Libraries BoostBook Documentation Subset">
<link rel="up" href="../bbv2.html" title="Chapter&#160;41.&#160;Boost.Build V2 User Manual">
<link rel="prev" href="overview.html" title="Overview">
<link rel="next" href="reference.html" title="Reference">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<table cellpadding="2" width="100%"><tr>
<td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../boost.png"></td>
<td align="center"><a href="../../../index.html">Home</a></td>
<td align="center"><a href="../../../libs/libraries.htm">Libraries</a></td>
<td align="center"><a href="http://www.boost.org/users/people.html">People</a></td>
<td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td>
<td align="center"><a href="../../../more/index.htm">More</a></td>
</tr></table>
<hr>
<div class="spirit-nav">
<a accesskey="p" href="overview.html"><img src="../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../bbv2.html"><img src="../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="reference.html"><img src="../../../doc/src/images/next.png" alt="Next"></a>
</div>
<div class="section">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="bbv2.tasks"></a>Common tasks</h2></div></div></div>
<div class="toc"><dl>
<dt><span class="section"><a href="tasks.html#bbv2.tasks.programs">Programs</a></span></dt>
<dt><span class="section"><a href="tasks.html#bbv2.tasks.libraries">Libraries</a></span></dt>
<dt><span class="section"><a href="tasks.html#bbv2.tasks.alias">Alias</a></span></dt>
<dt><span class="section"><a href="tasks.html#bbv2.tasks.installing">Installing</a></span></dt>
<dt><span class="section"><a href="tasks.html#bbv2.builtins.testing">Testing</a></span></dt>
<dt><span class="section"><a href="tasks.html#bbv2.builtins.raw">Custom commands</a></span></dt>
<dt><span class="section"><a href="tasks.html#bbv2.reference.precompiled_headers">Precompiled Headers</a></span></dt>
<dt><span class="section"><a href="tasks.html#bbv2.reference.generated_headers">Generated headers</a></span></dt>
<dt><span class="section"><a href="tasks.html#bbv2.tasks.crosscompile">Cross-compilation</a></span></dt>
</dl></div>
<p>
    This section describes main targets types that Boost.Build supports
    out-of-the-box. Unless otherwise noted, all mentioned main target rules have
    the common signature, described in <a class="xref" href="overview.html#bbv2.overview.targets" title="Declaring Targets">the section called &#8220;Declaring Targets&#8221;</a>.
  </p>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="bbv2.tasks.programs"></a>Programs</h3></div></div></div>
<a class="indexterm" name="idp212187408"></a><p>
      Programs are created using the <code class="computeroutput">exe</code> rule, which follows the
      <a class="link" href="overview.html#bbv2.main-target-rule-syntax">common syntax</a>. For
      example:
</p>
<pre class="programlisting">
exe hello : hello.cpp some_library.lib /some_project//library
          : &lt;threading&gt;multi
          ;
</pre>
<p>
      This will create an executable file from the sources&#8212;in this case, one
      C++ file, one library file present in the same directory, and another
      library that is created by Boost.Build. Generally, sources can include C
      and C++ files, object files and libraries. Boost.Build will automatically
      try to convert targets of other types.
    </p>
<div class="tip"><table border="0" summary="Tip">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="../../../doc/src/images/tip.png"></td>
<th align="left">Tip</th>
</tr>
<tr><td align="left" valign="top"><p>
        On Windows, if an application uses shared libraries, and both the
        application and the libraries are built using Boost.Build, it is not
        possible to immediately run the application, because the <code class="literal">PATH
        </code> environment variable should include the path to the
        libraries. It means you have to either add the paths manually, or have
        the build place the application and the libraries into the same
        directory. See <a class="xref" href="tasks.html#bbv2.tasks.installing" title="Installing">the section called &#8220;Installing&#8221;</a>.
      </p></td></tr>
</table></div>
</div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="bbv2.tasks.libraries"></a>Libraries</h3></div></div></div>
<a class="indexterm" name="idp212191712"></a><p>
      Library targets are created using the <code class="computeroutput">lib</code> rule, which
      follows the <a class="link" href="overview.html#bbv2.main-target-rule-syntax">common syntax
      </a>. For example:
</p>
<pre class="programlisting">
lib helpers : helpers.cpp ;
</pre>
<p>
      This will define a library target named <code class="computeroutput">helpers</code> built from
      the <code class="computeroutput">helpers.cpp</code> source file.
      It can be either a static library or a shared library,
      depending on the value of the <a class="link" href="reference.html#bbv2.overview.builtins.features.link">&lt;link&gt;</a> feature.
    </p>
<p>
      Library targets can represent:
      </p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p>
            Libraries that should be built from source,
            as in the example above.
          </p></li>
<li class="listitem"><p>
            Prebuilt libraries which already exist on the system.
            Such libraries can be searched for by the tools using them (typically
            with the linker's <code class="option">-l</code> option) or their paths can be
            known in advance by the build system.
          </p></li>
</ul></div>
<p>
    </p>
<p>
      The syntax for prebuilt libraries is given below:
</p>
<pre class="programlisting">
lib z : : &lt;name&gt;z &lt;search&gt;/home/ghost ;
lib compress : : &lt;file&gt;/opt/libs/compress.a ;
</pre>
<p>
      The <code class="computeroutput">name</code> property specifies the name of the library
      without the standard prefixes and suffixes.  For example, depending
      on the system, <code class="computeroutput">z</code> could refer to a file called
      z.so, libz.a, or z.lib, etc.  The <code class="computeroutput">search</code> feature
      specifies paths in which to search for the library in addition
      to the default compiler paths. <code class="computeroutput">search</code> can be specified
      several times or it can be omitted, in which case only the default
      compiler paths will be searched. The <code class="computeroutput">file</code> property
      specifies the file location.
    </p>
<p>
      The difference between using the <code class="computeroutput">file</code> feature and
      using a combination of the <code class="computeroutput">name</code> and <code class="computeroutput">search</code>
      features is that <code class="computeroutput">file</code> is more precise.
      
      </p>
<div class="warning"><table border="0" summary="Warning">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Warning]" src="../../../doc/src/images/warning.png"></td>
<th align="left">Warning</th>
</tr>
<tr><td align="left" valign="top">
<p>
          The value of the <code class="computeroutput">search</code> feature is just added to the
          linker search path.  When linking to multiple libraries,
          the paths specified by <code class="computeroutput">search</code> are combined without
          regard to which <code class="computeroutput">lib</code> target each path came from.
          Thus, given
</p>
<pre class="programlisting">
lib a : : &lt;name&gt;a &lt;search&gt;/pool/release ;
lib b : : &lt;name&gt;b &lt;search&gt;/pool/debug ;
</pre>
<p>
          If /pool/release/a.so, /pool/release/b.so, /pool/debug/a.so,
          and /pool/release/b.so all exist, the linker will probably
          take both <code class="computeroutput">a</code> and <code class="computeroutput">b</code> from the same
          directory, instead of finding <code class="computeroutput">a</code> in /pool/release
          and <code class="computeroutput">b</code> in /pool/debug.  If you need to distinguish
          between multiple libraries with the same name, it's safer
          to use <code class="computeroutput">file</code>.
        </p>
</td></tr>
</table></div>
<p>
    </p>
<p>
      For convenience, the following syntax is allowed:
</p>
<pre class="programlisting">
lib z ;
lib gui db aux ;
</pre>
<p>
      which has exactly the same effect as:
</p>
<pre class="programlisting">
lib z : : &lt;name&gt;z ;
lib gui : : &lt;name&gt;gui ;
lib db : : &lt;name&gt;db ;
lib aux : : &lt;name&gt;aux ;
</pre>
<p>
    </p>
<p>
      When a library references another library you should put that other
      library in its list of sources. This will do the right thing in all cases.
       For portability, you should specify
      library dependencies even for searched and prebuilt libraries, othewise,
      static linking on Unix will not work. For example:
</p>
<pre class="programlisting">
lib z ;
lib png : z : &lt;name&gt;png ;
</pre>
<p>
    </p>
<div class="note"><table border="0" summary="Note">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../../../doc/src/images/note.png"></td>
<th align="left">Note</th>
</tr>
<tr><td align="left" valign="top">
<p>
        When a library has a shared library as a source, or a static
        library has another static library as a source then any target
        linking to the first library with automatically link to its source
        library as well.
      </p>
<p>
        On the other hand, when a shared library has a static library as
        a source then the first library will be built so that it completely
        includes the second one.
      </p>
<p>
        If you do not want a shared library to include all the libraries specified
        in its sources (especially statically linked ones), you would need to
        use the following:
</p>
<pre class="programlisting">
lib b : a.cpp ;
lib a : a.cpp : &lt;use&gt;b : : &lt;library&gt;b ;
</pre>
<p>
        This specifies that library <code class="computeroutput">a</code> uses library <code class="computeroutput">b</code>,
        and causes all executables that link to <code class="computeroutput">a</code> to link to
        <code class="computeroutput">b</code> also. In this case, even for shared linking, the
        <code class="computeroutput">a</code> library will not refer to <code class="computeroutput">b</code>.
      </p>
</td></tr>
</table></div>
<p>
      
      <a class="link" href="overview.html#bbv2.overview.targets" title="Declaring Targets">Usage requirements</a> are often
      very useful for defining library targets. For example, imagine that
      you want you build a <code class="computeroutput">helpers</code> library and its interface is
      described in its <code class="computeroutput">helpers.hpp</code> header file located in the same
      directory as the <code class="computeroutput">helpers.cpp</code> source file. Then you could add
      the following to the Jamfile located in that same directory:
</p>
<pre class="programlisting">
lib helpers : helpers.cpp : : : &lt;include&gt;. ;
</pre>
<p>
      which would automatically add the directory where the target has been
      defined (and where the library's header file is located) to the compiler's
      include path for all targets using the <code class="computeroutput">helpers</code> library. This
      feature greatly simplifies Jamfiles.
    </p>
</div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="bbv2.tasks.alias"></a>Alias</h3></div></div></div>
<p>
      The <code class="computeroutput">alias</code> rule gives an alternative name to a
      group of targets. For example, to give the name <code class="filename">core</code>
      to a group of three other targets with the following code:
</p>
<pre class="programlisting">
alias core : im reader writer ;
</pre>
<p>
      Using <code class="filename">core</code> on the command line, or in the source list
      of any other target is the same as explicitly using <code class="filename">im
      </code>, <code class="filename">reader</code>, and <code class="filename">writer</code>.
    </p>
<p>
      Another use of the <code class="computeroutput">alias</code> rule is to change build properties.
      For example, if you want to use link statically to the Boost Threads
      library, you can write the following:
</p>
<pre class="programlisting">
alias threads : /boost/thread//boost_thread : &lt;link&gt;static ;
</pre>
<p>
      and use only the <code class="computeroutput">threads</code> alias in your Jamfiles.
    </p>
<p>
      You can also specify usage requirements for the <code class="computeroutput">alias</code> target.
      If you write the following:
</p>
<pre class="programlisting">
alias header_only_library : : : :  &lt;include&gt;/usr/include/header_only_library ;
</pre>
<p>
      then using <code class="computeroutput">header_only_library</code> in sources will only add an
      include path. Also note that when an alias has sources, their usage
      requirements are propagated as well. For example:
</p>
<pre class="programlisting">
lib library1 : library1.cpp : : : &lt;include&gt;/library/include1 ;
lib library2 : library2.cpp : : : &lt;include&gt;/library/include2 ;
alias static_libraries : library1 library2 : &lt;link&gt;static ;
exe main : main.cpp static_libraries ;
</pre>
<p>
      will compile <code class="filename">main.cpp</code> with additional includes
      required for using the specified static libraries.
    </p>
</div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="bbv2.tasks.installing"></a>Installing</h3></div></div></div>
<p>
      This section describes various ways to install built target and arbitrary
      files.
    </p>
<h4>
<a name="idp212223904"></a>Basic install</h4>
<p>
      For installing a built target you should use the <code class="computeroutput">install</code>
      rule, which follows the <a class="link" href="overview.html#bbv2.main-target-rule-syntax">
      common syntax</a>. For example:
</p>
<pre class="programlisting">
install dist : hello helpers ;
</pre>
<p>
      will cause the targets <code class="computeroutput">hello</code> and <code class="computeroutput">helpers</code> to be
      moved to the <code class="filename">dist</code> directory, relative to the
      Jamfile's directory. The directory can be changed using the
      <code class="computeroutput">location</code> property:
</p>
<pre class="programlisting">
install dist : hello helpers : &lt;location&gt;/usr/bin ;
</pre>
<p>
      While you can achieve the same effect by changing the target name to
      <code class="filename">/usr/bin</code>, using the <code class="computeroutput">location</code> property is
      better as it allows you to use a mnemonic target name.
    </p>
<p>
      The <code class="computeroutput">location</code> property is especially handy when the location
      is not fixed, but depends on the build variant or environment variables:
</p>
<pre class="programlisting">
install dist : hello helpers :
    &lt;variant&gt;release:&lt;location&gt;dist/release
    &lt;variant&gt;debug:&lt;location&gt;dist/debug ;
install dist2 : hello helpers : &lt;location&gt;$(DIST) ;
</pre>
<p>
      See also <a class="link" href="reference.html#bbv2.reference.variants.propcond" title="Conditional properties">conditional
      properties</a> and <a class="link" href="faq.html#bbv2.faq.envar" title="Accessing environment variables">environment
      variables</a>
    </p>
<h4>
<a name="idp212230656"></a>Installing with all dependencies</h4>
<p>
      Specifying the names of all libraries to install can be boring. The
      <code class="computeroutput">install</code> allows you to specify only the top-level executable
      targets to install, and automatically install all dependencies:
</p>
<pre class="programlisting">
install dist : hello
           : &lt;install-dependencies&gt;on &lt;install-type&gt;EXE
             &lt;install-type&gt;LIB
           ;
</pre>
<p>
      will find all targets that <code class="computeroutput">hello</code> depends on, and install all
      of those which are either executables or libraries. More specifically, for
      each target, other targets that were specified as sources or as dependency
      properties, will be recursively found. One exception is that targets
      referred with the <a class="link" href="reference.html#bbv2.builtin.features.use">
      <code class="computeroutput">use</code></a> feature are not considered, as that feature is
      typically used to refer to header-only libraries. If the set of target
      types is specified, only targets of that type will be installed,
      otherwise, all found target will be installed.
    </p>
<h4>
<a name="idp212233856"></a>Preserving Directory Hierarchy</h4>
<a class="indexterm" name="idp212234048"></a><p>
      By default, the <code class="computeroutput">install</code> rule will strip paths from its
      sources. So, if sources include <code class="filename">a/b/c.hpp</code>, the
      <code class="filename">a/b</code> part will be ignored. To make the
      <code class="computeroutput">install</code> rule preserve the directory hierarchy you need to
      use the <code class="literal">&lt;install-source-root&gt;</code> feature to specify
      the root of the hierarchy you are installing. Relative paths from that
      root will be preserved. For example, if you write:
</p>
<pre class="programlisting">
install headers
    : a/b/c.h
    : &lt;location&gt;/tmp &lt;install-source-root&gt;a
    ;
</pre>
<p>
      the a file named <code class="filename">/tmp/b/c.h</code> will be created.
    </p>
<p>
      The <a class="link" href="reference.html#bbv2.reference.glob-tree">glob-tree</a> rule can be
      used to find all files below a given directory, making it easy to install
      an entire directory tree.
    </p>
<h4>
<a name="idp212238576"></a>Installing into Several Directories</h4>
<p>
      The <a class="link" href="tasks.html#bbv2.tasks.alias" title="Alias"><code class="computeroutput">alias</code></a> rule can be
      used when targets need to be installed into several directories:
</p>
<pre class="programlisting">
alias install : install-bin install-lib ;
install install-bin : applications : /usr/bin ;
install install-lib : helper : /usr/lib ;
</pre>
<p>
    </p>
<p>
      Because the <code class="computeroutput">install</code> rule just copies targets, most free
      features <sup>[<a name="idp212240736" href="#ftn.idp212240736" class="footnote">15</a>]</sup> have no
      effect when used in requirements of the <code class="computeroutput">install</code> rule. The
      only two that matter are <a class="link" href="reference.html#bbv2.builtin.features.dependency">
      <code class="varname">dependency</code></a> and, on Unix, <a class="link" href="reference.html#bbv2.reference.features.dll-path"><code class="varname">dll-path</code>
      </a>.
    </p>
<div class="note"><table border="0" summary="Note">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="../../../doc/src/images/note.png"></td>
<th align="left">Note</th>
</tr>
<tr><td align="left" valign="top"><p>
        (Unix specific) On Unix, executables built using Boost.Build typically
        contain the list of paths to all used shared libraries. For installing,
        this is not desired, so Boost.Build relinks the executable with an empty
        list of paths. You can also specify additional paths for installed
        executables using the <code class="varname">dll-path</code> feature.
      </p></td></tr>
</table></div>
</div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="bbv2.builtins.testing"></a>Testing</h3></div></div></div>
<p>
      Boost.Build has convenient support for running unit tests. The simplest
      way is the <code class="computeroutput">unit-test</code> rule, which follows the <a class="link" href="overview.html#bbv2.main-target-rule-syntax">common syntax</a>. For example:
</p>
<pre class="programlisting">
unit-test helpers_test : helpers_test.cpp helpers ;
</pre>
<p>
    </p>
<p>
      The <code class="computeroutput">unit-test</code> rule behaves like the
      <a class="link" href="tasks.html#bbv2.tasks.programs" title="Programs">exe</a> rule, but after the executable is created
      it is also run. If the executable returns an error code, the build system
      will also return an error and will try running the executable on the next
      invocation until it runs successfully. This behaviour ensures that you can
      not miss a unit test failure.
    </p>
<p>
      By default, the executable is run directly. Sometimes, it is desirable to
      run the executable using some helper command. You should use the <code class="literal">
      testing.launcher</code> property to specify the name of the helper
      command. For example, if you write:
</p>
<pre class="programlisting">
unit-test helpers_test
   : helpers_test.cpp helpers
   : <span class="bold"><strong>&lt;testing.launcher&gt;valgrind</strong></span>
   ;
</pre>
<p>
      The command used to run the executable will be:
</p>
<pre class="screen">
<span class="bold"><strong>valgrind</strong></span> bin/$toolset/debug/helpers_test
</pre>
<p>
    </p>
<p>
       There are few specialized testing rules, listed below:
</p>
<pre class="programlisting">
rule compile ( sources : requirements * : target-name ? )
rule compile-fail ( sources : requirements * : target-name ? )
rule link ( sources + : requirements * : target-name ? )
rule link-fail ( sources + : requirements * : target-name ? )
</pre>
<p>
      They are given a list of sources and requirements. If the target name is
      not provided, the name of the first source file is used instead. The
      <code class="literal">compile*</code> tests try to compile the passed source. The
      <code class="literal">link*</code> rules try to compile and link an application from
      all the passed sources. The <code class="literal">compile</code> and <code class="literal">link
      </code> rules expect that compilation/linking succeeds. The <code class="literal">
      compile-fail</code> and <code class="literal">link-fail</code> rules expect that
      the compilation/linking fails.
    </p>
<p>
      There are two specialized rules for running applications, which are more
      powerful than the <code class="computeroutput">unit-test</code> rule. The <code class="computeroutput">run</code> rule
      has the following signature:
</p>
<pre class="programlisting">
rule run ( sources + : args * : input-files * : requirements * : target-name ?
    : default-build * )
</pre>
<p>
      The rule builds application from the provided sources and runs it, passing
      <code class="varname">args</code> and <code class="varname">input-files</code> as command-line
      arguments. The <code class="varname">args</code> parameter is passed verbatim and
      the values of the <code class="varname">input-files</code> parameter are treated as
      paths relative to containing Jamfile, and are adjusted if <span class="command"><strong>bjam
      </strong></span> is invoked from a different directory. The
      <code class="computeroutput">run-fail</code> rule is identical to the <code class="computeroutput">run</code> rule,
      except that it expects that the run fails.
    </p>
<p>
      All rules described in this section, if executed successfully, create a
      special manifest file to indicate that the test passed. For the
      <code class="computeroutput">unit-test</code> rule the files is named <code class="filename"><em class="replaceable"><code>
      target-name</code></em>.passed</code> and for the other rules it is
      called <code class="filename"><em class="replaceable"><code>target-name</code></em>.test</code>.
      The <code class="computeroutput">run*</code> rules also capture all output from the program, and
      store it in a file named <code class="filename"><em class="replaceable"><code>
      target-name</code></em>.output</code>.
    </p>
<p>
      <a class="indexterm" name="idp212260144"></a>
      If the <code class="literal">preserve-test-targets</code> feature has the value
      <code class="literal">off</code>, then <code class="computeroutput">run</code> and the <code class="computeroutput">run-fail</code>
      rules will remove the executable after running it.  This somewhat decreases
      disk space requirements for continuous testing environments. The default 
      value of <code class="literal">preserve-test-targets</code> feature is <code class="literal">on</code>.      
    </p>
<p>
      It is possible to print the list of all test targets (except for
      <code class="computeroutput">unit-test</code>) declared in your project, by passing the <code class="literal">
      --dump-tests</code> command-line option. The output will consist of
      lines of the form:
</p>
<pre class="screen">
boost-test(<em class="replaceable"><code>test-type</code></em>) <em class="replaceable"><code>path</code></em> : <em class="replaceable"><code>sources</code></em>
</pre>
<p>
    </p>
<p>
      It is possible to process the list of tests, Boost.Build output
      and the presense/absense of the <code class="filename">*.test</code>
      files created when test passes into human-readable status table of tests.
      Such processing utilities are not included in Boost.Build.
    </p>
</div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="bbv2.builtins.raw"></a>Custom commands</h3></div></div></div>
<p>
      For most main target rules, Boost.Build automatically figures out
      the commands to run.  When you want to use new
      file types or support new tools, one approach is to extend Boost.Build to
      support them smoothly, as documented in <a class="xref" href="extender.html" title="Extender Manual">the section called &#8220;Extender Manual&#8221;</a>.
      However, if the new tool is only used in a single place, it
      might be easier just to specify the commands to run explicitly.
    </p>
<p>
      
      Three main target rules can be used for that. The <code class="computeroutput">make
      </code> rule allows you to construct a single file from any number
      of source file, by running a command you specify. The <code class="computeroutput">
      notfile</code> rule allows you to run an arbitrary command,
      without creating any files. And finaly, the <code class="computeroutput">generate
      </code> rule allows you to describe a transformation using
      Boost.Build's virtual targets. This is higher-level than the file names that
      the <code class="computeroutput">make</code> rule operates with and allows you to
      create more than one target, create differently named targets depending on
      properties or use more than one tool.
    </p>
<p>
      The <code class="computeroutput">make</code> rule is used when you want to create
      one file from a number of sources using some specific command. The
      <code class="computeroutput">notfile</code> is used to unconditionally run a
      command.
    </p>
<p>
      Suppose you want to create the file <code class="filename">file.out</code> from
      the file <code class="filename">file.in</code> by running the command <span class="command"><strong>
      in2out</strong></span>. Here is how you would do this in Boost.Build:
</p>
<pre class="programlisting">
make file.out : file.in : @in2out ;
actions in2out
{
    in2out $(&lt;) $(&gt;)
}
</pre>
<p>
      If you run <span class="command"><strong>b2</strong></span> and <code class="filename">file.out</code> does
      not exist, Boost.Build will run the <span class="command"><strong>in2out</strong></span> command to
      create that file. For more details on specifying actions, see <a class="xref" href="overview.html#bbv2.overview.jam_language.actions">the section called &#8220;Boost.Jam Language&#8221;</a>.
    </p>
<p>
      It could be that you just want to run some command unconditionally, and
      that command does not create any specific files. For that you can use the
      <code class="computeroutput">notfile</code> rule. For example:
</p>
<pre class="programlisting">
notfile echo_something : @echo ;
actions echo
{
    echo "something"
}
</pre>
<p>
      The only difference from the <code class="computeroutput">make</code> rule is
      that the name of the target is not considered a name of a file, so
      Boost.Build will unconditionally run the action.
    </p>
<p>
      
      The <code class="computeroutput">generate</code> rule is used when you want to
      express transformations using Boost.Build's virtual targets, as opposed to
      just filenames. The <code class="computeroutput">generate</code> rule has the
      standard main target rule signature, but you are required to specify the
      <code class="literal">generating-rule</code> property. The value of the property
      should be in the form <code class="literal">
      @<em class="replaceable"><code>rule-name</code></em></code>, the named rule should
      have the following signature:
</p>
<pre class="programlisting">
rule generating-rule ( project name : property-set : sources * )
</pre>
<p>
      and will be called with an instance of the <code class="computeroutput">project-target</code>
      class, the name of the main target, an instance of the
      <code class="computeroutput">property-set</code> class containing build properties, and the list
      of instances of the <code class="computeroutput">virtual-target</code> class corresponding to
      sources. The rule must return a list of <code class="computeroutput">virtual-target</code>
      instances. The interface of the <code class="computeroutput">virtual-target</code> class can be
      learned by looking at the <code class="filename">build/virtual-target.jam</code>
      file. The <code class="filename">generate</code> example contained in the
      Boost.Build distribution illustrates how the <code class="literal">generate</code>
      rule can be used.
    </p>
</div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="bbv2.reference.precompiled_headers"></a>Precompiled Headers</h3></div></div></div>
<p>
      Precompiled headers is a mechanism to speed up compilation by creating a
      partially processed version of some header files, and then using that
      version during compilations rather then repeatedly parsing the original
      headers. Boost.Build supports precompiled headers with gcc and msvc
      toolsets.
    </p>
<p>
      To use precompiled headers, follow the following steps:
    </p>
<div class="orderedlist"><ol class="orderedlist" type="1">
<li class="listitem"><p>
          Create a header that includes headers used by your project that you
          want precompiled. It is better to include only headers that are
          sufficiently stable &#8212; like headers from the compiler and
          external libraries. Please wrap the header in <code class="computeroutput">#ifdef
          BOOST_BUILD_PCH_ENABLED</code>, so that the potentially expensive
          inclusion of headers is not done when PCH is not enabled. Include the
          new header at the top of your source files.
        </p></li>
<li class="listitem">
<p>
          Declare a new Boost.Build target for the precompiled header and add
          that precompiled header to the sources of the target whose compilation
          you want to speed up:
</p>
<pre class="programlisting">
cpp-pch pch : pch.hpp ;
exe main : main.cpp pch ;
</pre>
<p>
          You can use the <code class="computeroutput">c-pch</code> rule if you want to
          use the precompiled header in C programs.
        </p>
</li>
</ol></div>
<p>
      The <code class="filename">pch</code> example in Boost.Build distribution can be
      used as reference.
    </p>
<p>
      Please note the following:
    </p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem"><p>
          The inclusion of the precompiled header must be the first thing in a
          source file, before any code or preprocessor directives.
        </p></li>
<li class="listitem"><p>
          The build properties used to compile the source files and the
          precompiled header must be the same. Consider using project
          requirements to assure this.
        </p></li>
<li class="listitem"><p>
          Precompiled headers must be used purely as a way to improve
          compilation time, not to save the number of <code class="computeroutput">#include</code>
          statements. If a source file needs to include some header, explicitly
          include it in the source file, even if the same header is included
          from the precompiled header. This makes sure that your project will
          build even if precompiled headers are not supported.
        </p></li>
<li class="listitem"><p>
          On the gcc compiler, the name of the header being precompiled must be
          equal to the name of the <code class="computeroutput">cpp-pch</code> target. This is a gcc
          requirement.
        </p></li>
<li class="listitem"><p>
          Prior to version 4.2, the gcc compiler did not allow anonymous
          namespaces in precompiled headers, which limits their utility. See the
          <a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29085" target="_top"> bug
          report</a> for details.
        </p></li>
</ul></div>
</div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="bbv2.reference.generated_headers"></a>Generated headers</h3></div></div></div>
<p>
      Usually, Boost.Build handles implicit dependendies completely
      automatically. For example, for C++ files, all <code class="literal">#include</code>
      statements are found and handled. The only aspect where user help might be
      needed is implicit dependency on generated files.
    </p>
<p>
      By default, Boost.Build handles such dependencies within one main target.
      For example, assume that main target "app" has two sources, "app.cpp" and
      "parser.y". The latter source is converted into "parser.c" and "parser.h".
      Then, if "app.cpp" includes "parser.h", Boost.Build will detect this
      dependency. Moreover, since "parser.h" will be generated into a build
      directory, the path to that directory will automatically added to include
      path.
    </p>
<p>
      Making this mechanism work across main target boundaries is possible, but
      imposes certain overhead. For that reason, if there is implicit dependency
      on files from other main targets, the <code class="literal">&lt;implicit-dependency&gt;
      </code> feature must be used, for example:
</p>
<pre class="programlisting">
lib parser : parser.y ;
exe app : app.cpp : &lt;implicit-dependency&gt;parser ;
</pre>
<p>
      The above example tells the build system that when scanning all sources of
      "app" for implicit-dependencies, it should consider targets from "parser"
      as potential dependencies.
    </p>
</div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="bbv2.tasks.crosscompile"></a>Cross-compilation</h3></div></div></div>
<a class="indexterm" name="idp212295504"></a><p>Boost.Build supports cross compilation with the gcc and msvc
    toolsets.</p>
<p>
      When using gcc, you first need to specify your cross compiler
      in <code class="filename">user-config.jam</code> (see <a class="xref" href="overview.html#bbv2.overview.configuration" title="Configuration">the section called &#8220;Configuration&#8221;</a>), 
      for example:</p>
<pre class="programlisting">
using gcc : arm : arm-none-linux-gnueabi-g++ ;
</pre>
<p>
      After that, if the host and target os are the same, for example Linux, you can
      just request that this compiler version to be used:
    </p>
<pre class="screen">
b2 toolset=gcc-arm
</pre>
<p>
      If you want to target different operating system from the host, you need
      to additionally specify the value for the <code class="computeroutput">target-os</code> feature, for
      example:
    </p>
<pre class="screen">
# On windows box
b2 toolset=gcc-arm <span class="bold"><strong>target-os=linux</strong></span>
# On Linux box
b2 toolset=gcc-mingw <span class="bold"><strong>target-os=windows</strong></span>
</pre>
<p>
      For the complete list of allowed opeating system names, please see the documentation for 
      <a class="link" href="reference.html#bbv2.reference.features.target-os">target-os feature</a>.
    </p>
<p>
      When using the msvc compiler, it's only possible to cross-compiler to a 64-bit system
      on a 32-bit host. Please see <a class="xref" href="reference.html#v2.reference.tools.compiler.msvc.64" title="64-bit support">the section called &#8220;64-bit support&#8221;</a> for
      details.
    </p>
</div>
<div class="footnotes">
<br><hr width="100" align="left">
<div class="footnote"><p><sup>[<a id="ftn.idp212240736" href="#idp212240736" class="para">15</a>] </sup>see the definition of "free" in <a class="xref" href="reference.html#bbv2.reference.features.attributes" title="Feature Attributes">the section called &#8220;Feature Attributes&#8221;</a>.</p></div>
</div>
</div>
<table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr>
<td align="left"></td>
<td align="right"><div class="copyright-footer">Copyright &#169; 2006-2009 Vladimir Prus<p>Distributed under the Boost Software License, Version 1.0.
      (See accompanying file <code class="filename">LICENSE_1_0.txt</code> or copy at 
      <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>)
      </p>
</div></td>
</tr></table>
<hr>
<div class="spirit-nav">
<a accesskey="p" href="overview.html"><img src="../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../bbv2.html"><img src="../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="reference.html"><img src="../../../doc/src/images/next.png" alt="Next"></a>
</div>
</body>
</html>
